User-Centred Requirements Handbook |
The results of the prototype test and the task acceptability review are considered. If the prototype appears to be successful, the design can be used as a basis for the user requirements specification which is carried out in Phase 3.
Phase 3
User requirements documentation
Phase 3 of the user requirements specification process consist of the third iteration around the user-centred design loop as shown below.
• Requirements: This phase include stating requirements for the system in general including the general characteristics of the system and the organisational structure on which it is based. User goals and tasks, the technical environment and functions and features are also described. The user interface design approach and user support requirements are documented. The physical and social environment that will be created is described as well as a plan for testing the implemented system.
• Design: To support the design phase, an implementation plan is produced. This will include what actions will be taken to make users aware of the new system, and what training is to be provided. If system phasing is required, it will include a description of the migration path from the user's point of view. Also it will include a list of internal guides or external standards that should be referred to during implementation.
• Test: A plan will also be developed to specify how feedback on system usage, usability and acceptability will be collected while the system is in use.
Figure 9. Phase 3 - user requirements Documentation
The previous two stages will have produced a series of potential user requirements that should be considered as a basis for agreed user requirements which will form the basis of the user requirements specification.
The design team and user representatives should go through each of the requirements specified in Phases 1 and 2, copy each potential user requirement across to one of the following sections in Phase 3.
Once all these potential requirements have been copied into the following sections, they should be reviewed by the design team and users and the following stages carried out:
• Any duplicate requirements in any particular session should be removed.
• Any other requirements that do not seem needed or are superseded by other requirements should also be excluded.
• Any new requirements which arise from the review of each section below should be added.
Once the requirements have been carefully reviewed in this way, they should be written up as a Draft User Requirements Specification document. This may be structured using the headings presented in Stage 3 below. The document must then be reviewed by representatives of the development team with users in order to check or validate the user requirements. For any requirements that users are unsure about or which they think are missing, it will be necessary to go back (or trace) the relevant sections of the Framework and to clarify or add a requirement, as necessary.
The sections for compiling the user requirements, initially, are presented below.
Requirements prioritisation
It is important to prioritise the user requirements listed in the following tables. A column labelled 'Pri' within each of the following tables should be used for this. This prioritisation should be achieved by assembling a rating team comprising end users, marketing and industry personnel, managers, and technical designers. Once the user requirements have been assembled, the rating team will consider each requirement one at a time and assign a priority from 1 to 5 to each requirement, where 1 is 'critical' or 'vitally important' and 5 is 'unimportant'. If a rating as low as 5 is actually assigned to a requirement, consideration should then be given as to whether it can be deleted to simplify the specification.
Some items, e.g. the hardware to be used, are given as part of the system rather than as a requirement. These items are labelled 'Con.', to indicate that they are constraints on the design. Other items are simply statements of flexibility in the design e.g. the labelling and colour of keys requirement. These items are labelled 'Flex'.
For a more details about prioritising user requirements, see the QFD process (Fehin, 1997).
Requirements achievement
It is also important to monitor progress in achieving the user requirements as the design process continues. This should be done at meetings of the design team. For each requirement, the progress in achieving it should be estimated. Then either 1, 2 or 3 asterisks are written into the column marked 'Ach'. One asterisk * represents some progress, two asterisks ** equals considerable progress, and three asterisks *** indicates that the requirement fully achieved. If no progress has been made, then the cell is left blank.
It is possible to estimate the current level of progress in achieving the user requirements by means of the following calculation:
Sum of ( Each priority assignment, 1 to 5 X Progress level, 1 to 3 )
(Total of the priority assignments X 3)
This value will be a proportion which can then be converted into a percentage by multiplying it by 100. Thus if each requirement is fully met (progress level 3), the current achievement level will be 100%. However in practice, not all requirements will be fully met, and the design team will be looking to achieve the highest percentage as possible. In setting some level of acceptability it may, for instance, be decided that all requirements with a rating of 3 or more must be fully met.